<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<!doctype html>
<html>
<head>
  <title>NJEdit</title>
  <link rel="stylesheet" href="header.css" type="text/css">
  <link rel="stylesheet" href="index.css" type="text/css">
</head>
<body>

<%
String title = "Introducing NJEdit";
boolean isFaq = false;
%>
<%@ include file="header.inc" %>

<div id="content">

<p style="margin-top: 0">
<b>NJEdit</b> is a <a href="http://en.wikipedia.org/wiki/WYSIWYM" target="_blank">WYSIWYM</a>
editor of sorts that I created in order to draft the manuscript for
<i><a href="http://www.amazon.com/gp/product/1449381871?ie=UTF8&tag=bolinfestcom-20&link_code=as3&camp=211189&creative=373489&creativeASIN=1449381871" target="_blank">Closure: The Definitive Guide</a></i>.
I named it NJEdit because it was implemented in the spirit of the so-called
<a href="http://www.dreamsongs.com/RiseOfWorseIsBetter.html" target="_blank">New Jersey approach</a>. 
Rather than implement a general-purpose word processing application (of which there are many),
NJEdit supports only the formatting options that I needed to produce my manuscript.

<p>
As the primary output of the editor is a representation of the document in
<a href="http://en.wikipedia.org/wiki/DocBook" target="_blank">Docbook XML</a>
that can be consumed by the
production team at O'Reilly (which is ultimately transformed into a version that
is suitable for publication to print), NJEdit constrains the set of formatting
options to those that can be realized in DocBook.
More specifically, it only supports the set of features of DocBook
<em>that I needed to use</em>.
For example, as I never encountered the need for boldface text while writing my
book, I never added such a feature to NJEdit.

<p>
Originally, NJEdit was implemented as a Firefox extension
(using <a href="http://groups.csail.mit.edu/uid/chickenfoot/" target="_blank">Chickenfoot</a>,
of course) so that it had the security permissions to include code snippets from
source code on local disk.
(This was done to ensure that my code samples and my manuscript would be in sync.)
By using Firefox as my platform, I was able to leverage all of my knowledge of
JavaScript/HTML/CSS to implement NJEdit while I was simultaneously inhibited
by the quirks of content-editable HTML elements. Despite these tradeoffs, I was
able to construct an editor with the following features:

<ul>
  <li>In NJEdit, a document is a sequence of paragraphs where each paragraph is a member
      from a fixed set of types: prose, code sample, heading (three levels), 
      list item, or XML blob (this last type was my "escape hatch" that prevented
      me from having to support every little feature of DocBook in NJEdit).
      Changing the type of the paragraph is achieved by hitting
      <code>ctrl+enter</code> while the cursor is in the paragraph.
      This is considerably easier than fiddling with the mouse to highlight
      the appropriate section and then choosing the formatting style from a menu.
      Further, it also guarantees that all paragraphs of the
      same type are formatted in exactly the same way.
  <li>Because Firefox was used as the platform for NJEdit, each paragraph type
      could be rendered using the appropriate HTML and CSS. Therefore, unlike a view of
      the raw Docbook XML in a text editor, the view of the document in NJEdit
      had some resemblance to what the final product would look like.
      The other way to gain insight to how the final product would look was to
      upload the Docbook XML to O'Reilly which would produce a PDF of what the
      book would look like in print, but that process was far too slow to be
      done frequently.
  <li>Text that should appear in the constant width font used for code samples
      is delimited by backticks, so instead of typing
      <code>&lt;code>functionCall()&lt;/code></code> as you would in an ordinary
      text editor, you would simply type <code>`functionCall()`</code>.
      In the course of producing a 500+ page manuscript of technical writing,
      this becomes a huge savings, as a document littered with <code>&lt;code></code>
      markup would be a distraction while both reading and writing.
  <li>Hitting <code>ctrl+S</code> saves the current version of the HTML to
      Google Docs. By being more lightweight than a commit to O'Reilly's
      Subversion repository, this greatly reduced the cost of saving intermediate
      versions. Further, Google Docs has a decent UI that understands HTML when
      comparing versions of a document. By comparison, I do not find the output
      of <code>diff</code> to be an effective visualization of what has changed.
</ul>


<p>
Although NJEdit was implemented from a "works for me" perspective, I decided to
port it to a webapp as others may find it useful.
Further, I have open-sourced the code and made it available on
<a href="http://code.google.com/p/docbookeditor/" target="_blank">Google Code</a>.
Personally, I plan to continue to use NJEdit to write technical articles such as
<a href="http://bolinfest.com/javascript/inheritance.php" target="_blank">
"Inheritance Patterns in JavaScript"</a>, but if others find it useful and want
to contribute, then I will happily accept patches.

<a class="get-started-anchor" href="editor.jsp">
<div class="get-started">
Get Started Using NJEdit (requires access to Google Docs)
</div>
</a>

<!-- 

When I brought on my contributing editor, Julie Parent, who fortunately had the
patience to tolerate the editing tool I had cobbled together, updating the tool
became more of a pain 


<p>
Unlike most text editors that you use as a software engineer, such as Emacs
or vi, NJEdit is 

It was built using web technologies so it could leverage the browser for
the presentation layer. 
I decided to create my own editor because most of the available options fell
into one of the following categories:

<ul>
  <li>A full-blown word processor like Microsoft Word.
  <li>A raw markup language like XML or LaTeX.
</ul>

<p>
The problem with a full-blown word processor is that it has too many features: a
product like Microsoft Word offers virtually unlimited formatting options,
making it possible to create a document of any kind. In practice, I only needed
to create a specific type of document&mdash;a technical book&mdash;and the only
formatting options that I cared about were the ones supported by my publisher
(82-column limits on code samples, special formatting for tips and warnings, etc.).
Ideally, the publisher-supported options would be easily accessible and all other
formatting options would be hidden, as they would be lost in the production
process, anyway. Further, removing such options eliminated potential distractions
and made it easier to focus on producing content.

<p>
The problem with using raw text is that it is verbose with respect to markup:
when writing a technical manuscript that is full of references to code,
it is extremely tedious to type <code>&lt;code>&lt;/code></code> over and over
again. Further, working in raw text makes it hard to visualize what the final
product will look like, and build steps to produce the final product (such as
compiling LaTeX to a PDF) become a time-consuming distraction if you do it
frequently.

<p>
What I really wanted was something like the
<a href="http://googlesystem.blogspot.com/2009/10/fullscreen-google-tasks.html">
full screen version of Google Tasks</a>: a lightweight, HTML-based editor that
provides just enough structure beyond a plaintext file to be incredibly useful.

<p>
wfMEdit has the following advantages that made it optimal for
<ul>
  <li>The version of 
</ul>

wfMEdit has the following <b>disadvantages</b> that make it a pain to use:

<ul>
  <li>It is buggy. As the author of the tool, it was not too hard for me to work
      around the bugs (or even fix them if they bothered me enough!).
</ul>
 -->

</div>
<div id="sidebar">

  <a href="http://www.amazon.com/gp/product/1449381871?ie=UTF8&tag=bolinfestcom-20&link_code=as3&camp=211189&creative=373489&creativeASIN=1449381871"
     target="_blank">
    <img id="cover" src="/cover_big.png" alt="Closure: The Definitive Guide">
  </a>
  <b>NJEdit</b> was used to draft
  <i><a href="http://www.amazon.com/gp/product/1449381871?ie=UTF8&tag=bolinfestcom-20&link_code=as3&camp=211189&creative=373489&creativeASIN=1449381871" target="_blank">Closure: The Definitive Guide</a></i>.
  If you are writing a technical book or
  online essays that include code samples,
  then this may be the right tool for you.
  <!-- 
  <br>
  <a href="learnmore.html" target="_blank">Learn more</a>
  -->
</div>

<jsp:include page="analytics.jsp" />

</body>
</html>
